BITFTP provides a mail interface to the FTP portion of the IBM TCP/IP product ("FAL") running on the Princeton VM system, to allow BITNET/NetNorth/EARN users to ftp files from sites on the Internet.
To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC (or to BITFTP@PUCC.Princeton.edu).
The first command to BITFTP must be "FTP", "FTPLIST", "HELP", or "VMS". If you send BITFTP mail or a message containing only the command "FTPLIST", it will send you a list of some of the hosts that allow anonymous ftp. (Note that there is no guarantee that BITFTP can access all the hosts in that list.) Use "HELP" to request a current copy of this help file. Use "VMS" to request a collection of tips provided by BITFTP users on how to handle binary files from
BITFTP on VMS systems.
The recommended syntax for FTP requests is:
FTP hostname NETDATA --or-- FTP hostname UUENCODE
USER username password
<other ftp subcommands>
QUIT
Following the hostname on the FTP command, you may specify "UUENCODE" or "NETDATA" to tell BITFTP the format in which you wish to receive files.
If the username is "anonymous", no password is required; BITFTP will use your userid and nodeid as the password. Note that on many systems passwords are case-sensitive; that is, the password may be required to be in lower case or mixed case or upper case. (The same is true of directory and file names.)
The following is an example of an ftp request:
FTP f.ms.uky.edu NETDATA
USER anonymous
CD /pub/msdos/Games
DIR
BINARY
GET robotron.arc msdos.robotron
QUIT
BITFTP implements a subset of the ftp subcommands provided in the IBM TCP/IP and uses the same syntax. Therefore, you may find it useful to obtain the "IBM TCP/IP for VM Command Reference Manual", IBM order number GC09-1204.
The currently supported subcommands are:
ACCT -- to send host-dependent account information.
format: ACCT account-information
ASCII -- to change the file transfer type to ASCII.
format: ASCII
BINARY -- to change the file transfer type to image.
format: BINARY <FIXED record-len> <VARIABLE>
CD -- to change the working directory.
format: CD directory
CLOSE -- to disconnect from the foreign host.
format: CLOSE
DIR -- to get a list of directory entries.
format: DIR
EBCDIC -- to change the file transfer type to EBCDIC
format: EBCDIC
GET -- to get a file from the foreign host.
format: GET foreignfile <localfile>
If you specify "localfile", it must be in
the forms "filename.filetype" or "filename",
and the filename and filetype may each be no
more than 8 characters long and may not contain
periods.
LOCSTAT -- to display local status information.
format: LOCSTAT
LS -- to list the files in a directory.
format: LS <name>
PWD -- to print the working directory.
format: PWD
QUIT -- to disconnect from the foreign host.
format: QUIT
STATUS -- to retrieve status information from a foreign host.
format: STATUS <name>
SYSTEM -- to get the name of the foreign host's operating
system.
format: SYSTEM
TYPE -- to specify Image, ASCII, or EBCDIC file transfer.
format: TYPE <I|A|E>
BITFTP does not provide a PUT capability, and there is no intention
to make it do so in the future.
BITFTP currently accepts requests only via RFC822-format mail, IBM NOTE-format mail, PROFS-format messages, or files with no headers at all.
BITFTP currently returns the requested files as NETDATA-format files or as mail files containing UUENCODED data. If you specify
"UUENCODE" or "NETDATA" on your "FTP" command, BITFTP will attempt to use that format. If you do not specify the format, BITFTP will attempt to select the appropriate format for your node.
UUENCODED files are broken up into mail files that contain no more than 50,000 bytes of data. NETDATA-format files that are larger than 300,000 bytes are sent in 300,000-byte pieces using the BITSEND function.
You should be able to receive such files using the BITRCV function available from your nearest NETSERV.
(If you do not know how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator
for assistance.) If BITRCV is not available for your system, use the command you normally use to receive NETDATA-format files and then concatenate the files in the order shown in the BITRCV control file to recover the original file.
Users in the UK should note that BITFTP attempts to send NETDATA-format files through the gateway from EARN into Janet via the NIFTP facility at Rutherford Lab. Note that receiving files via NIFTP requires an overt action on your part.
If you are at a Janet node and don't know how to use NIFTP, you should ask for assistance locally. Alternatively, you can ask BITFTP to send your files UUENCODED inside mail by specifying the "UUENCODE" option.
If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is to make sure that you specified ASCII if the file should contain textual material or that you specified BINARY if the file should contain binary data, executable programs, tar files, or the like. VMS users should specify BINARY F 512 and should use RECEIVE/BINARY to receive the NETDATA-format binary files BITFTP sends them.
If BITFTP sends you a uuencoded file that you cannot uudecode, the first thing to do is to translate all occurrences of 0x7E in the file to 0x5E and then try uudecoding again. (Some gateways are changing 5Es to 7Es when the files pass through them.)
There are many different flavors of UUENCODE/UUDECODE.
The version that BITFTP uses puts a "guard character" at the end of each encoded line.
Most implementations of uudecode know to ignore this character. If yours does not, then you should remove the last
character of each line before attempting to uudecode the file.
Note that the guard character is not always "M"; the short lines at the end of the file may have some other guard character, rather than "M".
Whatever that character is, it should be removed (or your uudecode should be fixed).
When BITFTP is told to transfer a file in FIXED format, such as "BINARY FIXED 128", it will create a file whose total byte count is an integral multiple of the record length (128, in this case).
This means that the last record may be padded to get it to the specified record length. In such a case, you may need to use an editor to shorten the last record so that the total byte count in the file is correct. (If the file is uuencoded when you receive it, shorten it AFTER you have uudecoded it.)
In addition to any files you request, you will also receive a mail file containing a log of your ftp session. In that mail file,
entries prefixed by ">" are your original commands; those prefixed by ">>" are your commands as interpreted by BITFTP and passed to TCPIP; those prefixed by ">>>" are your commands as interpreted by TCPIP and passed to the remote host; those prefixed by "<<<" are messages from the remote host; and those prefixed by ">>>>" are completion messages from BITFTP.
If BITFTP is unable to connect to the host you specify, it will send you mail after the first attempt, but will keep trying at intervals over three days. The only additional mail file you will receive will be when the connection is made successfully or when BITFTP gives up after three days.
The load on BITFTP is often very heavy, and network backlogs are often so great that it may take several days for a file to get to you once BITFTP sends it, so please be patient and don't send multiple requests for the same file. If your system allows you to send interactive messages, you can inquire about BITFTP's backlog by sending the query "How are you?", e.g., on a VM system:
TELL BITFTP AT PUCC How are you?
Questions about BITFTP and suggestions for improvements should be directed to Melinda Varian, MAINT@PUCC on BITNET or maint@pucc.princeton.edu on the Internet.
The author gratefully acknowledges the use of the FTP SUBCOM interface written by David Nessl, the SENDJANI EXEC written by Alan Flavell, the uuencoding utility written by John Fisher, and the RFC822 parsing routine written by Eric Thomas. NOTE: If you have any complaints or suggestions about the way any of these routines work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not to the authors.
LIST OF HOSTS THAT ACCEPT ANONYMOUS FTP REQUESTS
This is my list of Internet sites accepting anonymous ftp:
user name: anonymous
password: <your mail address> (i.e. "odin@pilot.njin.net")
This list is posted to comp.misc, comp.sources.wanted, and alt.sources.wanted on Usenet and is distributed via anonymous FTP from pilot.njin.net (128.6.7.38) as well as being available from several other FTP sites (see list). I don't have the time to read the *.sources.wanted news- groups so if there is anything you want me to see, please use email. There
is also a mailing list which was being used to distribute the list, now I use it more for getting feedback on new ideas. If you wish to be added to the mailing list mail me at pilot.
Special thanks goes to Ed Vielmetti for all the work he does posting new archive information to comp.archives.
If there are any corrections/updates/etc. to be made please mail me at odin@pilot.njin.net. That also goes for descriptions of the archives. I don't have time to personally check each and every site so if you use a site
regularly and can put together a better description, please tell me so I can update this list. This is especially true for sites described as "unknown" or with vague descriptions. Those sites are ones that I either didn't have enough time to sort through it or I couldn't tell what was available.
REMINDER: Anonymous FTP is a privilege, not a right. The site administrators for the sites listed below have made their systems available out of the good- ness of their hearts. Please respect their wishes and restrict your FTPing
to non-prime hours (1900 - 0600 hours local time for the site). This is especially true for sites not in your country. Please keep that in mind when you are FTPing. None of us want to see sites start to close down because a few are being inconsiderate.
